Компания Veeam Software, ведущий поставщик средств для управления виртуальной инфраструктурой VMware vSphere, объявила о выпуске средства для резервного копирования виртуальных машин на серверах VMware ESX / ESXi - Veeam Backup and Replication 5.

Это действительно новый и революционный продукт, выводящий на новый уровень технологии резервного копирования виртуальных машин. Теперь оно стало еще более эффективным, а, с точки зрения механизмов восстановления данных и надежности, на сегодняшний день Veeam Backup and Replication 5 - абсолютный лидер в сегменте продуктов для резервного копирования VMware vSphere.

Мы уже писали об основных нововведениях Veeam Backup and Replication 5 с технологиями vPower, SureBackup, U-AIR и другими в следующих статьях:

• vPower - новые возможности Veeam Backup and Replication 5
• Демонстрация технологии SureBackup в Veeam Backup and Replication 5
• Издания Veeam Backup and Replication 5 - обзор возможностей
• Veeam SureBackup - новые возможности Veeam Backup and Replication 5

Теперь обо всех новых функциях и возможностях Veeam Backup and Replication 5 расскажем по порядку:

1. Технология Veeam vPower в Veeam Backup and Replication 5.

Используя множество техник, компания Veeam в своем продукте для резервного копирования виртуальных машин сделала возможность запуска их напрямую из резервных копий, которые хранятся в дедуплицированном виде на backup-хранилище. Это создает множество возможностей для тестирования резервных копий на работоспособность (SureBackup), мгновенного восстановления в производственную среду (InstantRestore) и даже управления виртуальными тестовыми лабораториями на базе продуктивных окружений (то есть, можно запустить продуктив напрямую из бэкапа для каких-нибудь тестов). Таким образом, Veeam vPower - это фундаментальная технология для множества улучшений в Veeam Backup and Replication 5.

2. Техника Instant VM Recovery (InstantRestore) в Veeam Backup and Replication 5.

InstantRestore позволяет мгновенно (без копирования каких-либо данных) восстановить резервную копию системы, запустив ее напрямую из резервной копии, которая хранится в сжатом и дедуплицированном виде. Далее виртуальная машина потихоньку переносит свое хранилище в продуктивную среду за счет технологии Storage VMotion. Если по лицензии VMware vSphere у вас нет техники Storage vMotion, то можно использовать репликацию виртуальной машины в производственное окружение - ведь репликация в Veeam Backup and Replication 5 бесплатна! Все это влияет самым лучшим образом на политики RTO (Recovery Time Objective) сервиса в виртуальной машине, позволяя восстановить его сразу после отказа.

3. Техника U-AIR (Universal Application-Item Recovery) в Veeam Backup and Replication 5.

U-AIR позволяет восстанавливать объекты приложений виртуальных машин напрямую из образа резервной копии. То есть, из бэкапа можно достать и восстановить на целевой сервер объект Active Directory, письмо Exchange или любой другой объект приложения. Кроме того, есть возможность самостоятельного восстановления данных пользователем из приложений с веб-фронтендом. Заметьте - не надо никаких агентов для восстановления отдельных объектов.

4. Техника SureBackup в Veeam Backup and Replication 5.

Veeam SureBackup позволяет убедиться в том, что резервные копии сделаны правильно и они полностью готовы к восстановлению и работе в случае аварии или потери данных. Делается это автоматизированным способом за счет создания виртуальной тестовой лаборатории, где виртуальные машины запускаются напрямую из бэкапов, не мешая основной производственной среде. Далее администратор вручную или автоматически (по заданию) верифицирует целостность хранимых копий, в том числе с помощью специальных скриптов, которые проверяют работоспособность не только ОС, но и приложений. Об отработавшей задаче проверки целостности резервных копий системному администратору приходит отчет по почте.

5. Виртуальная лаборатория по запросу (On-Demand Sandbox) в Veeam Backup and Replication 5.

С помощью техник мгновенного запуска резервных копий администратор может запустить набор приложений в виртуальных машинах, являющихся копией производственной среды, и проводить там какие угодно тесты. Для тестовой лаборатории задается хост ESX / ESXi, где это будет происходить, Datastore, Proxy Appliance для доступа Veeam Backup к тестовой лаборатории с виртуальными машинами в изолированной сети и настройки этой самой сети. После того, как виртуальная лаборатория создана, появится новый виртуальный коммутатор vSwitch, пул ресурсов и хранилище для тестирования.

6. Мгновенное восстановление файлов (Instant File Level Recovery) для любой гостевой ОС в Veeam Backup and Replication 5.

Veeam Backup всегда умел восстанавливать отдельные файлы из бэкапов гостевых систем виртуальных машин. Windows, Linux, FreeBSD и многое другое поддерживается для восстановления (при этом есть удобный навигатор по файловой системе). Теперь также появляется еще одна интересная возможность - монтирование диска резервной копии к виртуальной машине, куда требуется восстановить нужные файлы. Это очень удобно, а восстановление занимает считанные секунды.

7. Быстрый поиск объектов (Instant Indexing) в Veeam Backup and Replication 5.

Функция Instant Indexing - это быстрая индексация данных содержимого резервных копий виртуальных машин, что позволяет быстро искать в бэкапах любые файлы и мгновенно вытаскивать их в продуктивную среду. Также есть удобный браузер по файловым системам в Veeam Enterprise Manager.

• Customizable block size. Теперь можно настраивать размер блока для хранилища назначения резервной копии или реплики. Большой размер блока уменьшает затраты вычислительных ресурсов на бэкап и повышает производительность, в то время как меньший размер блока увеличивает степень дедупликации и позволяет уменьшить передаваемый трафик (что особенно актуально для WAN-соединений) при инкрементальном резервном копировании.
• Monthly schedules. Теперь можно настроить планировщик по месяцам для задач резервного копирования напрямую из GUI, который предоставляет больше опций нежели стандартный планировщик Windows.
• Continuous job schedule. Новая возможность создания задач по расписанию для соответствия сценариям near-CDP protection.
• Unsupported disks are now automatically skipped. Неподдерживаемые диски для резервного копирования теперь автоматически пропускаются (раньше надо было исключать их из задачи вручную).

• Incremental backup mode. Традиционный режим инкрементального резервного копирования теперь тоже есть для поддержки сценариев резервного копирования disk-to-disk-to-tape (D2D2T), удаленных сайтов и на хранилища, которые дедуплицируются своими средствами. Синтетический режим резервного копирования (обратные инкременты) также остался. Кроме того, можно восстанавливать систему даже тогда, когда отрабатывает задача по резервному копированию.
• Previous full backup chain transformation. Возможность преобразовать цепочки предыдущих полных бэкапов (Full Backups) в цепочку с одним полным бэкапом и несколькими обратными инкрементами для экономии дискового пространства на целевом хранилище.
• VM level retention in full backup files. Теперь в файле полной резервной копии просто заменяются блоки данных в соответствии с настроенной политикой хранения полных резервных копий. То есть, нет необходимости делать полный бэкап, полностью удаляя предыдущий из VBK-файла.
• Delete individual VMs from full backup file. Теперь можно удалить любую виртуальную машину из резервной копии с VBK-файлом. Блоки помечаются как свободные, и на их место записываются дальнейшие данные бэкапов без роста размера файла.
• Enhanced backup properties. Расширенные настройки в опциях для задачи резервного копирования.

• Thin disk support on replica. Теперь у реплики также может быть растущий по мере наполнения данными (thin) диск. Это улучшает производительность репликации.
• On-the-fly disk transformation. Также можно на лету при репликации преобразовывать "толстые" (thick) диски исходной машины в тонкие (thin) диски реплики. Экономия на дисковом хранилище реплик.
• Replica properties. Появились новые свойства реплики, такие как объем данных переданный с после запуска задачи репликации (функция, о которой запрашивали многие пользователи).

• Network connection-less operation. Теперь нет необходимости прямого соединения виртуальной машины, где работает Veeam VSS Agent, и бэкап-сервера. Это позволяет соблюсти политики безопасности в виртуальной инфраструктуре без потери функциональности по обеспечению целостности данных за счет служб VSS.
• Granular application-aware processing. Теперь можно более структурированно задавать настройки выполнения различных задач (например, запуск службы VSS) для отдельных виртуальных машин или других объектов виртуальной инфраструктуры VMware vSphere.
• Better transaction logs handling. Теперь лог транзакций приложения резервируемой системы очищается только после успешного бэкапа, вместо того, чтобы делать это после снятия снапшота при создании резервной копии. Это позволяет сохранить лог транзакций и откатиться на нужную точку в Microsoft SQL Server, даже если задача резервного копирования по какой-либо причине упадет после снятия снапшота виртуальной машины.
• Option to disable transaction logs pruning. Можно также полностью отключить очистку лога транзакций.
• Transaction logs pruning for Microsoft SQL. Очистка лога транзакций для Microsoft SQL Server была введена на случай, если этот сервер резервируется только средствами Veeam Backup и требуется, чтобы логи транзакций не разрастались.

• VM search. В мастер восстановления добавлена возможность поиска файлов, чтобы быстро найти файлы, которые требуется восстановить из резервной копии виртуальной машины.
• Restore reason. Можно указать причину восстановления файла - удобно для администраторов, отслеживающих эти события.
• Restore audit. Теперь в логе восстановления видно, кто и какие файлы восстанавливал, а также по какой причине.
• Service-based restores. Теперь задача восстановления файлов управляется службой Windows, поэтому даже если пользователь вышел из системы - задача продолжится.
• Original VM location prefill. Мастер восстановления теперь предлагает по умолчанию куда восстанавливать виртуальную машину, чтобы пользователь не ошибся.
• Per-disk datastore selection. Для виртуальной машины с несколькими виртуальными дисками можно указать разные хранилища (datastores) для каждого диска.
• Better guest file permission handling. Теперь для задачи восстановления файлов добавляется привилегия для доступа к томам, на которые у пользователя нет разрешений. Делается это только для движка Veeam Backup и не нарушает политик безопасности.
• Removed VMware Player requirement. Виртуальный модуль File level restore helper appliance теперь запускается напрямую на хосте VMware ESX / ESXi. Теперь не надо использовать VMware Player на сервере Veeam Backup.
• Preserve Linux permissions. Теперь можно сохранить права доступа в Linux при восстановлении отдельных файлов.
• Permissions and ownership display. Браузер по файловой системе теперь показывает разрешения и владельца файлов.
• ZFS support. Восстановление файлов с томов ZFS теперь поддерживается.

• Datastore based jobs. Теперь можно создавать задачи, добавляя Datastore как объект для резервирования. Все машины на этом хранилище будут добавлены в задачу.
• Granular disk exclusions. Вместо того, чтобы настраивать исключения для дисков на базе задач, можно настраивать исключения на уровне виртуальных машин или других объектов виртуальной инфраструктуры VMware vSphere. Например, в каком-то пуле вы хотите исключить бэкап диска D виртуальных машин.
• Per-job email notification. Для каждой задачи отдельно можно настроить нотификацию по e-mail (для разных пользователей).
• Windows Event Log events.Veeam Backup теперь пишет о своих действиях в журнал Windows event log (в стиле vCenter).
• Simple delegation. Механизм доступа на базе ролей в Veeam Backup был добавлен для разграничения действий пользователей. Например, Restore Operator может выполнять любой тип восстановления, однако не может работать с задачами резервного копирования.
• Source datastore monitoring. Как вы знаете, снапшоты требуют дополнительное пространство на хранилище при создании и слиянии. Теперь мониторинг исходного хранилища позволяет убедиться в том, что не возникнет ситуации переполнения, когда из-за нее виртуальные машины завершат работу. По умолчанию, предупреждение высвечивается в случае, если остается менее 10 ГБ свободного пространства. Если остается менее 2 ГБ - задача резервного копирования будет пропущена.
• Session history improvements. Старые сессии восстановления теперь удаляются на базе политики хранения, что актуально для пользователей старых версий Veeam Backup, у которых много чего накопилось с более ранних версий.

• Centralized license management. Теперь удобно отслеживать использующиеся лицензии на Veeam Backup на нескольких серверах из центральной консоли Veeam Enterprise Manager.
• Dashboard statistic improvements. Теперь информация о занимаемом пространстве резервными копиями более детальна.

• Database name selection. Теперь можно привязать несколько бэкап-серверов Veeam Backup к одной базе Microsoft SQL.
  Disabling automount. Теперь автомонтирование новых томо автоматически отключается на сервере Veeam Backup при установке, чтобы предотвратить переподписку VMFS-томов со стороны Microsoft Windows. Теперь этого не надо бояться забыть сделать вручную.
  CPU verification. Теперь проверяется, достаточно ли мощности CPU для установки Veeam Backup. При этом требования к CPU сохранились от предыдущей версии.

Безусловно, Veeam Backup and Replication 5 - лучший продукт для резервного копирования виртуальных машин в инфраструктуре VMware vSphere. Скачать его можно по этой ссылке.

Купить Veeam Backup and Replication 5 можно уже сегодня. Для этого используйте форму заказа у Золотого партнера Veeam Software на территории России - компании VMC.

Как вы знаете, есть замечательное ПО StarWind Enterprise HA, которое позволяет создать отказоустойчивое хранилище для виртуальных машин VMware vSphere или Microsoft Hyper-V, на базе технологии iSCSI. Мы уже писали о StarWind здесь, здесь, здесь и здесь, а сегодня мы расскажем о том, какие требования к узлам предъявляет ПО StarWind Enterprise.

CPU

Рекомендуется процессор Intel Xeon E5620 или выше либо эквивалентный ему AMD Opteron. Надо отметить, что рекомендуется использовать многоядерные CPU. При этом, если сравнивать CPU, у которого частота каждого из ядер меньше, с CPU с большей частотой ядер, но меньшим их количеством - то предпочтителен первый вариант. То есть, лучше иметь 6-ядерный Intel Xeon 5660 с частотой 2.8 ГГц на ядро, чем 4-ядерный Intel Xeon 5667 с частотой 3.02 ГГц на ядро.

RAM

Минимум нужно 4 ГБ (для самой Windows и движка StarWind). Если вы используете один из методов кэширования в StarWind - то потребуется дополнительная память на кэши, исходя из их размеров.

Network

Естественно нужно использовать как минимум гигабитную сеть хранения iSCSI (при этом помните, что каждый компонент сети должен поддерживать 1 Гбит). Лучше использовать NIC Teaming для расширения канала или сети 10G, а также большие кадры Jumbo Frames (9K). Помните, что канал синхронизации между узлами обязательно нуждается в дублировании.

HDD

Можно использовать устройства SATA, SAS или SSD. Естественно, используйте аппаратные RAID-массивы, а не программные в производственной среде. Узнавать о том, какой RAID лучше начните отсюда.

Операционная система

Рекомендованная - Windows Server 2008 R2. Можно использовать и Windows Server 2003 (все, что выше - поддерживается). Также можно использовать и издания Server Core и даже бесплатный Hyper-V Server, однако, по понятным причинам, GUI для StarWind нужно будет устанавливать на отдельный компьютер (этот компонент называется StarWind Management Console). При этом для управления можно использовать и рабочую станцию с ОС, начиная с Windows XP. Помните, что для управления надо открыть порт 3261 в сетевом экране.

Сам процесс установки и настройки ПО StarWind Enterprise на каждом из узлов занимает 10-30 минут, поэтому просто возьмите и попробуйте продукт бесплатно.

Кстати, вроде бы из нового - появился вот такой документ "How to Increase VMware Application Availability with Shared Storage". И да, обязательно смотрите вот сюда и сюда.

Многим пользователям платформы виртуализации VMware vSphere известна компания StarWind, которая производит продукт StarWind Enterprise для создания отказоустойчивых хранищ под серверы VMware ESX (описание работы - здесь, изданий - здесь). Основная фишка данного продукта - использование двухузлового кластера, работающего в режиме Active-Passive или Active-Active, который в случае падения одного из узлов продолжает свою работу, а виртуальные машины не теряют данных. Эта вещь актуальна для организаций, которую используют существующую инфраструктуру Ethernet для создания сети хранения на базе технологии iSCSI. То есть для тех, кто не любит тратить деньги направо и налево, покупая Fibre Channel системы хранения.

По заявкам наших читателей мы публикуем объяснение работы кластера StarWind Enterprise в случае обрыва канала синхронизации между узлами (так называемый сценарий Split Brain). В актуальной версии StarWind Enterprise 5.4 при обрыве канала синхронизации между узлами обе ноды оставались работающими, думая что каждая из них - выживший член кластера.

В этом случае, например, при алгоритме балансировки Round Robin (или при переключении пути после разрыва канала синхронизации) могла выйти ситуация, когда данные писались то на одну ноду, то на другую (а данные между ними не синхронизировались). Соответственно, при попытке что-нибудь прочитать - мы получали Blue Screen в гостевой ОС. Поэтому настоятельно рекомендовалось использовать дублирование канала синхронизации (NIC Teaming).

В версии StarWind Enteprise 5.5 которая у меня уже есть на руках (и вы можете ее у меня попросить), а у вас будет совсем скоро, ситуация кардинально лучше. Теперь механизм работы кластера StarWind HA следующий:

Когда ноды работают в режиме Active-Active, между ними все равно есть распределение ролей - Primary и Secondary.

Если обрывается канал синхронизации между узлами (нет пинга), то:

• По каналу Heartbeat (сеть iSCSI трафика) первичный узел посылает запрос вторичному узлу на то, жив ли он (обычный ping). Если он жив, то первичный узел посылает вторичному узлу команду на отключение всех клиентов (ESX) от этого узла. Соответственно все команды процессятся через первичный узел и ситуации Split Brain не возникает. При налаживании канала синхронизации - оба узла синхронизируются (второй получает данные от первого) и работа в режиме Active-Active продолжается.
• Если Heartbeat по сети iSCSI-трафика не прошел. Это значит умер вторичный узел, а не канал синхронизации. Соответственно, ESX продолжает запись на первичную ноду до того, как вторичный узел не придет в себя. После этого опять произойдет синхронизация и кластер StarWind HA продолжит свою работу.

Вторичная нода тоже пингует первичную при разрыве канала синхронизации на случай если упал сам первичный узел, а не канал синхронизации. Если ответа нет - она продолжает работу по записи данных на диск. После восстановления канала синхронизации с этой нодой синхронизируется первичный узел и конфигурация Active-Active восстанавливается.

Скачать продукт StarWind Enteprise можно по этой ссылке. Купить StarWind можно по этой ссылке.

Часто бывает необходимо заглянуть в логи сервера VMware ESX или ESXi и посмотреть, что там происходит. При обнаружении и решении проблем работы серверов виртуализации с хранилищами логи - это главный источник ваших знаний о том, что с ними случилось.

Если сервер ESX / ESXi работает с хранилищем iSCS или Fibre Channel в режиме multipathing с одним активным путем к хранилищу, то описанная ниже последовательность шагов, которые выполняет ESX, может вам помочь при наступлении события переключения на резервный путь (failover)....

Компания StarWind, являющаяся спонсором VM Guru, предлагает своим пользователям один из лучших в индустрии продукт для создания отказоустойчивых хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V на базе технологии iSCSI. Преимущество StarWind Enterprse в том, что без существенных вложений в инфраструктуру Ethernet и сам продукт (он недорог) вы можете получить надежную, защищенную от отказов инфраструктуру хранения для виртуализации.

Почитать о принципе работы продукта StarWind Enterprise можно вот в этой статье.

Данное решение можно использовать в сегменте среднего и малого бизнеса, где дорого и сложно (административно) получить бюджеты на отказоустойчивые программно-аппаратные решения Enterprise-уровня. Кроме того, важная тема - создание виртуальной инфраструктуры филиалов, где стоит 3-5 серверов VMware ESX и 20-30 виртуальных машин.

Сейчас продукт StarWind Enterprise предлагается в 3-х изданиях:

• StarWind Enterprise CDP (лимит 4 ТБ): Это лицензия на 1 сервер, назначенный в качестве первичного контроллера хранилищ (например, томов VMFS), и включает в себя неограниченное количество одновременных клиентских iSCSI-подключений, поддержку технологии CDP/Snapshot. Это базовая лицензия - здесь нет синхронной репликации данных на резервный узел и самого резервного узла тоже нет.
• StarWind Enterprise Mirroring & Replication: Эта лицензия требуется для сервера, назначенного в качестве первичного контроллера хранилища, и включает неограниченное количество клиентских соединений и нелимитированную емкость хранения. Это издание StarWind позволяет реплицировать данные только в одну сторону (на вторичный узел) с первичного узла. То есть, с этой лицензией нельзя использовать два активных сервера хранения, а только активно-пассивную конфигурацию.
• StarWind Enterprise HA (лицензия на 2,4,8,16 и неограниченное число ТБ хранения): Лицензия StarWind Enterprise HA включает неограниченное количество клиентских iSCSI-соединений с лимитом емкости или без него для окружений, в которых необходима высокая доступность класса Active-Active (зеркалирование и удаленная репликация) с различным объемом хранения и числом серверов-контроллеров хранилищ. В рамках лицензии можно использовать одну или две пары серверов в конфигурации Active-Active.

Внимание: для всех изданий StarWind Enterprise в стоимость продукта уже включен 1 год технической поддержки и подписки на обновления. То есть, отдельно ее нужно приобретать только для последующих лет эксплуатации решения.

Теперь чем отличаются сами издания:

	StarWind Enterprise CDP Edition	StarWind Enterprise Mirroring & Replication Edition	StarWind Enterprise HA 2ТБ Edition	StarWind Enterprise HA 4ТБ Edition	StarWind Enterprise HA 8ТБ Edition	StarWind Enterprise HA 16ТБ Edition	StarWind Enterprise HA Unlimited
Поддержка	1 год	1 год	1 год	1 год	1 год	1 год	1 год
Количество серверов за лицензию	1	2	2	2	2	4 *	4 *
Максимальная мощность	4ТБ	Безлимит	2ТБ	4ТБ	8ТБ	16ТБ	Безлимит
Количество одновременных соединений ISCSI	Безлимит	Безлимит	Безлимит	Безлимит	Безлимит	Безлимит	Безлимит
Ethernet порты	Безлимит	Безлимит	Безлимит	Безлимит	Безлимит	Безлимит	Безлимит
Обслуживаемые диски	Безлимит	Безлимит	Безлимит	Безлимит	Безлимит	Безлимит	Безлимит
Файлы образов диска
IPSec, CHAP, ACL, iSNS
Сетевой мост
SPTI
CDP / Snapshots
Thin Provisioning
Высокоскоростное кэширование
Синхронное зеркалирование
Удаленная репликация
Автоматическое восстановление после отказа
Целостность данных с быстрой синхронизацией
Цена	$995.00	По запросу	По запросу	По запросу	По запросу	По запросу	По запросу

Приятный момент при покупке StarWind - вы покупаете какое-нибудь издание (например, базовое на один сервер), а потом решаете, что вам нужна высокая доступность. Вы делаете апгрейд - и платите только разницу в цене между изданиями, без диковинных наценок, которые появляются, например, у VMware.

Вы уже выучили, где продаются все продукты, о которых мы пишем? Правильно - в VMC.

Многим из вас, конечно же, давно знакома компания StarWind, делающая отличный продукт StarWind iSCSI Target, который позволяет превратить обычный сервер или недорогую систему хранения данных в надежное отказоустойчивое хранилище для виртуальных машин VMware vSphere или Microsoft Hyper-V.

У меня для вас приятная новость - поскольку StarWind теперь является официальным спонсором портала VM Guru, то вам, уважаемые читатели, теперь будет доноситься гораздо больше свежей, актуальной и детальной информации о продуктах этого вендора. И да, на VM Guru теперь есть раздел о StarWind (его вы видите в верхнем меню).

Что можно сказать о StarWind? Мы берем в свои рекламодатели только лучшие компании, делающие уникальные продукты для оптимизации ИТ-инфраструктуры предприятий. И StarWind - одна из них. Решение iSCSI Target - вообще безальтернативный продукт для стремительно растущего рынка виртуализации и его клиентов. О нем мы уже писали в статье "Как работает StarWind Enterprise HA - отказоустойчивое хранилище для VMware vSphere / ESX" - мы его используем каждый день в наших лабораториях, мы его устанавливаем клиентам, мы его настоятельно предлагаем покупать и некоторое его количество мы уже продали.

Но это мы делали и раньше. А вот начиная с нынешнего момента, мы будем вас посвящать в технические детали работы решений StarWind. Флагманский продукт компании - StarWind Enterprise HA позволяет сделать недорогую отказоустойчивую систему хранения из двух узлов, что защитит диски ваших виртуальных машин в случае выхода из строя одного из хранилищ. Переключение на резерв произойдет мгновенно - без потери каких бы то ни было данных. Это нужное решение и главная фишка в том, что оно недорогое, а каждая компания сможет себе выбрать подходящее издание.

Также есть еще масса интересных возможностей для создания хранилищ виртуальных машин на серверах VMware ESX и Hyper-V:

• Синхронное зеркалирование данных: зеркалирование данных в режиме реального времени через кластер хранения, состоящий из двух узлов
• Высокая доступность / Автоматическое преодоление отказа: отказоустойчивая технология исключает единую точку сбоя
• Восстановление с быстрой Синхронизацией: восстановление к оригинальному состоянию системы после автоматического восстановления
• Удаленная / асинхронная репликация: воспроизводит систему хранения данных на удаленный узел через сеть интернет
• Точки восстановления и мгновенные снимки (snapshots): создает точку восстановления с неограниченным количеством откатов
• Сервер кластеризации: обеспечивает общее хранилище для кластеризации серверов c высокой доступностью
• Тонкое резервирование: распределяет пространство динамично для высокоэффективного использования дисковых ресурсов

И бонус: сотрудники StarWind говорят по-русски, поэтому вы всегда сможете быть уверены, что вам помогут, а не будут бормотать в трубку что-то непонятное.

Теперь пул рекламодателей VM Guru окончательно сформирован, так что если хотите купить рекламу на VM Guru - обращайтесь, конечно, но придется обождать.

И да, компания VMC является одним из поставщиков продуктов StarWind Software и ее надежным партнером.

На многим известном сайте sanbarrow.com обнаружился интереснейший справочник по дискам VMDK, которые используются в платформах виртуализации VMware vSphere, Workstation, Server и других.

Кстати, интересный вопрос поднимается в самом конце страницы. Как восстанавливать данные с поврежденных vmfs-томов и дисков vmdk? Автор полагает, что только компания Ontrack сертифицирована VMware для оказания подобных услуг. Но говорит также, что они очень дороги (я это подтверждаю - сами туда обращались).

Между тем, где-то раз в три месяца люди обращаются к нам с подобной проблемой...

Компания VMware закончила разработку новой версии решения для виртуализации настольных ПК предприятия VMware View 4.5, которое позволяет разместить рабочие станции пользователей на серверах виртуализации, добившись существенной экономии на содержание парка настольных компьютеров, а также повысить управляемость и безопасность данной части инфраструктуры.

Одной из новых возможностей решения для виртуализаци настольных ПК VMware View 4.5 стала возможность организации ярусного хранения данных виртуальных машин (Tiered Storage), где для различных типов данных в зависимости от требований к производительности можно использовать различные типы устройств хранения.

Мы уже писали о средстве VMware View Composer, которое позволяет использовать связанные клоны (Linked Clones) в целях экономии дискового пространства. Composer использует один базовый образ виртуального ПК на основе которого развертываются новые унифицированные виртуальные ПК с данными пользователей.

Напомним некоторые понятия хранения данных виртуальных ПК:

• Master Replica – это основной образ виртуального ПК с установленной гостевой ОС и приложениями, хранимый как шаблон.
• Replica – это клон Master Replica на базе дисков растущих по мере наполнения (Thin Provisioned). Он создается для каждого нового пула виртуальных ПК на своем datastore. Этот образ используется для создания новых десктопов-связанных клонов, которые зависят только от Replica, что позволяет вносить изменения в Master Replica, не затрагивая дочерние виртуальные машины пула.
• Linked Clone – это связанный клон на базе реплики, который представляет собой совокупность:
  Измененные данные реплики (Delta Footprint) + Журнал (Log) + Диск с пользовательскими данными (User Data Disk)

В VMware View 4.5 появились новые типы дисков:

• Persistent Disk – это и есть старый User Data Disk, который теперь носит такое название. Можно хранить persistent disk внутри диска гостевой ОС либо на отдельном vmdk.
• Disposable Disk – это отдельный диск для хранения файлов подкачки гостевой ОС и временных файлов. View Manager удаляет эти файлы после выключения связанного клона. Этот тип диска позволяет замедлить рост данных, занимаемых виртуальным ПК.

Теперь Linked Clone представляет собой следующую комбинацию:

Измененные данные реплики (Delta Footprint) + Журнал (Log) + Диск с пользовательскими данными (Persistent Disk) + Временный диск (Disposable Disk)

Для чего это сделано? Очевидно, что эти типы данных, из которых состоит виртуальная машина требуют различного быстродействия, что ведет за собой хранение этих объектов на разных типах носителей.

Через View Administrator можно выбрать различные Datastores для описанных выше объектов, которые могут размещаться на флеш-носителях SSD (самые быстрые), Fibre Channel (помедленнее) и SATA (самые медленные). Само собой, чем быстрее носитель - тем он дороже, поэтому, например, реплику (которая одна для всего пула и всеми машинами используется) можно размещать на SSD.

А вот пользовательские диски можно размещать и на носителях SATA. Картина в целом такова:

Красиво? По-моему, самое оно для всяких там Enterprises.

На myvirtualcloud.net появился вот такой интересный калькулятор для расчета параметров хранилищ для виртуальных машин в рамках решения по виртуализации настольных ПК. Калькулятор ориентирован на продукт VMware View, однако может быть использован для любого решения, использующего в качестве платформы виртуализации VMware vSphere.

Поиграйтесь:

Давно я что-то не писал о своих друзьях из компании Veeam Software, который делают лучшее в мире средство резервного копирования Veeam Backup and Replication (больше здесь и здесь). Как вы знаете они сейчас интенсивно готовят к выпуску Veeam Backup and Replication 5, который будет иметь чудесную (не имеющую аналогов!) технологию SureBackup.

Недавно коллеги из Veeam выпустили открытый документ, где подытожили 7 основных причин, по которым пользователи выбирают именно Veeam Backup, а не всякую второсортную бурду: "7 Reasons to Choose Veeam".

Документ, конечно, маркетинговый, однако маркетинг компании Veeam Software лишь фиксирует то, что так долго и упорно нарабатывалось разработчиками и тестировщиками.

Итак, почему нужно выбирать именно Veeam Backup and Replication:

1. Самый быстрый в мире бэкап виртуальных машин VMware vSphere, позволяющий сузить окно резервного копирования настолько, что оно будет шириной со щель в дифракционной решетке. Именно Veeam использует все преимущества VMware vSphere API for Data Protection, технологию Changed Block Tracking, снапшоты, а также обрабатывает большинство необычных (даже немыслимых) ситуаций, которые могут возникнуть в процессе резервного копирования.

2. Самый простой в мире Restore виртуальных машин и их отдельных файлов. Интерфейс прост настолько, что даже пятилетний ребенок с помощью Drag and Drop вытащит из резервной копии свои файлы (посмотрите на жалкую пародию VMware Data Recovery). При этом Veeam Backup поддерживает не только Windows и Linux системы для восстановления, но и множество остальных nix-систем - и все это в нормальном GUI.

3. Единственные в своем роде возможности репликации, за которые не надо платить (посмотрите на расценки барыг, производящих тяжеловесные СРК). С помощью репликации в Veeam Backup and Replication можно сделать Disaster Recovery конфигурацию виртуальной инфраструктуры между двумя площадками, которая не требует дорогостоящих SAN-устройств и продуктов, а также позволяет защищать отдельные виртуальные машины на томах LUN, а не только весь том VMFS. Конечно же, Veeam Backup полностью поддерживает Microsoft VSS в гостевых ОС.

4. Защита от потерь данных в пределах одного сервера ESX. Если у вас что-то случится с сервером ESX или будут утеряны данные, реплики виртуальных машин на других серверах можно сразу же запустить, а, кроме того, можно автоматизировать любой процесс восстановления с помощью встроенной поддержки PowerShell.

5. Вы можете делать резервные копии и реплики на какие угодно устройства, включая локальные диски серверов VMware ESX. Чуваки из документа навострились делать реплики на локальные диски серверов на случай, если SAN почему-то сломается (все происходит в атоматическом режиме). В этом случае вы сможете мигом восстановить всю виртуальную инфраструктуру.

6. Veeam Backup - это также лучший способ использовать Off-site storage для бэкапов. Используете ленты? Не проблема. Записывайте на них бэкапы Veeam. Кроме того, у Veeam есть встроенные возможности дедупликации хранимых резервных копий (без дополнительной платы, опять-таки, в отличие от барыг) и функции синтетического бэкапа, позволяющие быстрее всего восстанавливать именно последнюю резервную копию.

7. Veeam Backup делает самые красивые ежедневные репорты о том, что все сделано, забэкаплено и защищено, а также имеет централизованную консоль управления серверами резервного копирования. Вам остается только расслабится в эти жаркие дни и думать об отпуске.

Вы уже прониклись всеми волшебными возможностями Veeam Backup and Replication, но все еще не знаете где его купить? Зал хором говорит: "У золотого партнера Veeam - компании VMC!". Там и скидочку дадут и о продукте квалифицированно расскажут.

Многие пользователи, применяющие платформу виртуализации VMware vSphere в своей виртуальной инфраструктуре, ищут возможности использования недорогого хранилища для виртуальных машин. В качестве одного из вариантов, для тестового или некритичного производственного окружения, можно рассмотреть организацию NFS-хранилища на базе Windows 2008 Server R2...

На сервере VMware ESX из состава vSphere, если запустить утилиту esxtop и перейти в категорию дисковой подсистемы (кнопка "d"), можно увидеть счетчик CMDS/s.

Что он значит? CMDS/s (Total commands per second) - это общее число SCSI - команд, передаваемых к системе хранения, включая операции ввода-вывода вывода виртуальных машин, а также сервисные команды (например, SCSI reservations). Если говорить о параметре IOPS (Input/Output Operations Per Second) - то это общее число операций ввода-вывода, представляющее сумму:

IOPS = Number of Read commands(READS/s) + Number of Write commands(WRITES/s)

Таким образом, число IOPS должно быть близко к CMDS/s, за исключением случаев, когда сервер VMware ESX активно работает с метаданными тома VMFS (например, создает и удаляет снапшоты).

Компания NetApp продолжает выпуск своих замечательных документов по использованию хранилищ для виртуальной инфраструктуры. Теперь NetApp выпустила документ Storage Best Practices for KVM on NetApp, который будет полезен пользователям платформы Red Hat Enteprise Virtualization.

Молодцы NetApp! Роман, ждем перевода на русский язык)

Компания VKernel продолжает выпуск бесплатных программных продуктов для виртуализации VMware vSphere. На этот раз это утилита VKernel StorageView, которая позволяет найти "узкие" места в инфраструктуре хранения виртуальных машин. Это обычное десктоп-приложение весом в 6 МБ, которое может быть установлено на рабочей станции администратора и позволяет найти соединения хостов ESX с наибольшими задержками (latency) к томам VMFS или NFS.

Возможности VKernel StorageView:

• Топ 5 путей хост / datastore с наибольшей latency
• Список виртуальных машин, которые используют эти пути
• Скорость обмена трафиком хранения для каждой ВМ в этих путях
• Сводная статистика по остальным парам хост / datastore, не вошедшим в топ 5
• Поддержка хранилищ NFS / iSCSI / FC

Скачать VKernel StorageView можно по этой ссылке.

Очень много вопросов поступает относительно того, для чего нужны снапшоты виртуальных машин (snapshots) на серверах VMware ESX. По-сути снапшоты - это зло, но иногда они оказываются полезны в очень ограниченных условиях (например, для проверки корректности работы обновления приложения или патча операционной системы). То есть эта та точка сохранения состояния виртуальной машины, к которой можно будет вернуться через небольшой промежуток времени. Ни в коем случае нельзя рассматривать снапшоты как альтернативу резервному копированию основных производственных систем, в силу множества проблем.

Одной из них является неочевидное поведение снапшотов при их удалении (применении к основному диску ВМ). В этом случае вам может понадобиться значительный объем свободного дискового пространства на томе VMFS, особенно когда у вас есть несколько снапшотов. Например, у вас есть виртуальная машина с 3-мя снапшотами следующих размеров:

Вы нажимаете кнопку Delete All в Snapshot Manager в vSphere Client, после чего происходит такая ситуация: Snapshot 3 "склеивается" со Snapshot 2, но при этом сам Snapshot 3 остается на томе VMFS:

При этом занятое дисковое пространство увеличивается на величину Snapshot 3 и составляет 90 ГБ. Далее, то, что получилось в Snapshot 2 (50 ГБ) склеивается со Snapshot 1 (10 ГБ), при этом Snapshot 2 и Snapshot 3 остаются. То есть дисковое пространство, занимаемое файлами виртуальных дисков и снапшотов на томе VMFS увеличивается до 140 ГБ:

Только после всего этого, результирующий Snaphot 1 (60 ГБ - сумма всех снапшотов) применяется к основному файлу виртуального диска VMDK. При этом сам виртуальный диск flat в размере не меняется, поскольку он фиксирован (изменяется только содержимое блоков). И только затем все снапшоты удаляются (все 140 ГБ).

Таким образом, на хранилище VMFS нам понадобится 80 ГБ дополнительного свободного пространства, если мы хотим, чтобы операция прошла успешно (зато потом освободится 60 ГБ от снапшотов).

У пользователей VMware vSphere / ESX иногда возникает ситуация, когда необходимо заглянуть на том VMFS и его содержимое с Windows-машины системного администратора (такое, например, может быть, когда у вас сломался единственный сервер VMware ESX, а содержимое тома VMFS надо скопировать). Кроме того, очень полезным бывает получить доступ к файловой системе диска VMDK, чтобы извлечь из него необходимую информацию, не запуская его в составе виртуальной машины.

Open Source VMFS Driver

В первом случае для просмотра содержимого и копирования данных с тома VMFS версии 3.x (VMware vSphere 4.0 сейчас работает на версии 3.33) нам понадобится Open Source-утилита VMFS Driver от компании Fluid Operations. Она выпускается в виде пакета для Windows или Linux операционной системы (работает на Java) и позволяет монтировать в режиме read only активно работающие тома VMFS, с которых запущены виртуальные машины. По-сути, это не драйвер, а обычное приложение, позволяющее просматривать и копировать содержимое томов VMFS на рабочую станцию администратора. Важно знать, что эта разработка официально не поддерживается со стороны VMware, кроме того у разработчиков для написания утилиты не было спецификаций VMFS. Кстати, сейчас уже поддерживаются thin-диски.

Чтобы начать использовать VMFS Driver наберите в командной строке (у вас должна быть установлена Java):

java -jar fvmfs.jar

VMware Disk Mount

Во втором случае для просмотра содержимого VMDK-диска вам понадобится пакет разработчика Virtual Disk Development Kit, в состав которого входит утилита VMware Disk Mount (vmware-mount.exe или vmware-mount.pl). Эта программа позволяет смонтировать виртуальный диск VMDK в ОС Windows или Linux и просматривать его содержимое как обычного диска, подключенного к компьютеру. Обратите внимание, что последняя версия Virtual Disk Development Kit выпущена 21 мая 2009 года (в тот же день, что и VMware vSphere), а это значит, что поддерживается не только формат виртуальных дисков VMware Workstation, но и VMware ESX 3.x / 4.x (в том числе виртуальные машины vSphere). Пользоваться данной CLI-утилитой очень просто, кроме того, несколько лет назад к ней писали различные GUI-надстройки, которые, вероятно, и сегодня можно использовать.

Пользоваться VMware Disk Mount очень просто - открываете cmd и выполняете команду (где e: - буква монтируемого диска):

vmware-mount e: "C:\alex\vms\vm1\vm1.vmdk"

Интересный пример совместного использования технологий HP и Microsoft показал нам Calvin Zito. За счет Live Migration в Hyper-V и репликации в массивах HP EVA происходит перемещение виртуальных машин между датацентрами (и серверами, и хранилищами). И все это делается на большие расстояния!

Итак, Long Distance Cluster Extension EVA Live Migration with Hyper-V:

Компания StarWind, известная своим продуктом StarWind Enteprise HA для создания отказоустойчивых iSCSI хранилищ под серверы виртуализации VMware vSphere, Citrix XenServer и Microsoft Hyper-V, выпустила интересный бесплатный продукт FCoE Initiator.

Программа устанавливается в ОС Windows и позволяет получить доступ к хранилищам данных Fibre Channel через сеть передачи данных Ethernet. Типа как данное решение позволяет существенно сэкономить на инфраструктуре доступа к SAN за счет имеющихся IP-сетей (особенно для виртуальной инфраструктуры). Fibre Channel умирает, господа. Данное решение позволит вам потихоньку начать избавляться от FC.

Мануал по StarWind FCoE Initiator находится здесь.

Компания VMware - одна из немногих, кто по-настоящему думает о том, как пользователи будут делать резервные копии своих производственных систем в виртуальных машинах. В VMware vSphere 4 появился новый механизм Changed Block Tracking (CBT), который значительно упрощает жизнь разработчикам ПО для резервного копирования виртуальных машин и значительно повышает эффективность этого процесса.

Давайте попробуем разобраться для чего нужен Changed Block Tracking в VMware vSphere. Прежде всего, напомним, что ранее решения для резервного копирования (например, лидер рынка Veeam Backup) должны были самостоятельно заботиться о том, какие блоки виртуальных дисков изменились с момента создания резервной копии, чтобы не копировать весь vmdk целиком. Это вызывало значительную нагрузку на сервер ESX версии 3.x, поскольку не было встроенного механизма отслеживания изменивашихся блоков, а разработчикам приходилось выкручиваться.

Теперь же Changed Block Tracking в VMware vSphere является частью интерфейса vStorage APIs for Data Protection (VADP), который состоит из двух компонентов VDDK (Virtual Disk Develoment Kit) и vSphere SDK (о них можно почитать в документе "Designing Backup Solutions for VMware vSphere").

Changed Block Tracking работает на уровне стека работы с хранилищами в модуле VMkernel и позволяет сторонним продуктам для резервного копирования вернуть список изменившихся блоков с момента последнего бэкапа.

CBT можно использовать для любого типа виртуальных дисков, включая тома VMFS / FS / iSCSI и NAS / NFS, за исключением томов Raw Device Mapping (RDM) в режиме физической совместимости а также дисков, привязанных к shared virtual SCSI bus. Кстати, размер блока для CBT - это не то же самое, что размер блока для тома VMFS (потому что работает на уровне отдельного vmdk).

Чтобы CBT работал для резервного копирования ваших ВМ, необходимо, чтобы они имели Virtual Hardware версии 7 и выше:

По умолчанию функции Changed Block Tracking на серверах VMware ESX отключены, это обусловлено тем, что CBT дает небольшую нагрузку на CPU сервера для решения своих задач. Однако решения для резервного копирования, в частности Veeam Backup, его включают для создания бэкапов только изменившихся блоков, что существенно (в разы!) повышает скорость создания резервных копий.

Changed Block Tracking начинает работать после включения виртуальной машины или создания мгновенного снимка (снапшота), который делает ПО для резервного копирования. На хранилище виртуальных машин появляется файл xxx-ctk.vmd фиксированного размера для каждого виртуального диска vmdk (на 10 ГБ диска приходится где-то 500 КБ ctk-файла):

В этом файле содержится список блоков, которые отслеживаются для vmdk с их актуальным состоянием с определенного момента времени, зафиксированном в ChangedId (изменились или нет). Данный подход важен не только для резервного копирования, но и для репликации виртуальных машин между хранилищами, где очень важно время синхронизации с репликой.

Напоминаем, что первым продуктом, который стал использовать технологию Changed Block Tracking в VMware vSphere был и остается Veeam Backup and Replication.

Компания Microsoft сделала доступным средство аудита для виртуальной инфраструктуры Hyper-V R2 на базе Windows Server 2008 R2. Утилита называется Best Practices Analyzer for Hyper-V, она бесплатна, позволяет просканировать серверы Hyper-V в вашей инфраструктуре и дать рекомендации по корректным настройкам:

В числе рекомендаций для виртуальных машин советы по настройке виртуального сетевого взаимодействия и хранилищ.

Еще на VMworld 2009 компания VMware анонсировала технологию Storage IO Control (SCIO), которая должна появиться в следующих релизах платформы виртуализации VMware vSphere (по слухам уже в версии 4.1). Суть данной технологии - корректное распределение нагрузки на систему хранения данных (СХД) для виртуальных машин.

Сейчас у виртуальных машин есть такие настройки как Shares для категории Disk, которые определяют приоритеты виртуальных машин по нагрузке на СХД в рамках одного сервера VMware ESX. То есть, если у нас есть два сервера VMware ESX и виртуальные машины на них, то приоритеты нагрузки на storage будут распределены следующим образом при наличии параметров shares:

То есть очередь дискового массива пропорционально делится между хостами VMware ESX, а уже для каждого хоста его процент очереди делится на части в зависимости от Shares виртуальных машин.

Такой механизм не отражает реальную ситуацию по отношению к требованиям виртуальных машин к вводу-выводу, поскольку даже наиболее критичные сервисы в виртуальных машинах на хосте VMware ESX в кластере не могут получить больше, чем 1/n от очереди массива для тома VMFS / LUN, где n - число хостов ESX.

Технология Storage IO Control (SCIO) позволяет изменить данную ситуацию за счет двух техник:

• Вычисление задержек (latency) на том VMFS для запуска механизма SCIO (говорят о 20ms и более)
• Изменение пропускной способности канала виртуальных машин хоста к СХД за счет изменения глубины очереди HBA-адаптера (device queue depth)

Регулировка очереди со стороны HBA-адаптера позволяет более корректно распределить нагрузку на СХД между сервисами в виртуальных машинах в соответствии с их параметрами shares:

Как мы видим, наиболее критичный сервис (красный цвет), при условиях заданных shares для нескольких хостов ESX, позволяет потреблять 60% от того, что может выдать дисковый массив для данного тома VMFS. Это соответствует соотношению:

1500 (shares сервиса) / 2500 (общие shares ВМ хостов) * 100% = 60%

Механизм Storage IO Control для хостов VMware ESX включается при превышении порога latency для тома VMFS, определяемого пользователем, что позволяет надежно защитить наиболее критичные сервисы в виртуальных машинах от всплесков нагрузки на систему хранения данных в виртуальной инфраструктуре.

У компании EMC, как у владельца VMware, скопилось огромное количество документов, рассказывающих о том, как правильно использовать решение VMware vSphere на дисковых массивах EMC Clariion, Symmtrix, DMX и других. Ниже приведен список основных документов EMC для платформы VMware ESX и виртуальных машин:

Основные гайдлайны:		Работа корпоративных приложений
Using EMC CLARiiON Storage with VMware vSphere and VMware Infrastructure		Using VMware ESX with Oracle Database and EMC CLARiiON Storage Systems
Using VMware vSphere with EMC Symmetrix Storage		EMC Virtual Infrastructure for Microsoft Applications—Data Center Solution Enabled by EMC Symmetrix V-Max and VMware vSphere 4
Using EMC Celerra Storage with VMware vSphere and VMware Infrastructure		EMC Virtual Infrastructure for Microsoft Exchange 2007 (VMware vSphere 4.0)
EMC Integrated Infrastructure for VMware Enabled by EMC Celerra NS-120		Deploying a Virtual Infrastructure for SAP with EMC and VMware Technologies
EMC Symmetrix V-Max and VMware Virtual Infrastructure		EMC Solutions for Microsoft SQL Server - EMC Celerra Unified Storage Platforms
Iomega StorCenter Pro NAS ix4 and ix2 with VMware ESX Server 3.5		EMC Virtual Architecture for Microsoft SharePoint Server 2007
Implementing Virtual Provisioning on EMC CLARiiON and Celerra with VMware Infrastructure		EMC Virtual Infrastructure for Microsoft and Oracle Applications - Enabled by EMC CLARiiON and VMware vSphere 4

Виртуализация, при всех своих несомненных плюсах, имеет один очевидный недостаток - единая точка отказа в виде системы хранения, где размещены все виртуальные машины. Ситуацию во многом спасает наличие средств по резервному копированию или репликации данных (например, Veeam Backup), однако, эти средства не могут обеспечить полностью непрерывную работу виртуальной инфраструктуры. StarWind Enteprise HA позволяет решить эту проблему.

Как мы уже писали, компания VMware сделала еще один тип виртуального SCSI-адаптера в VMware vSphere, который получил название VMware Paravirtual SCSI (PVSCSI). Паравиртуализованное устройство PVSCSI позволяет добиться большей производительности дисковой подсистемы витуальных машин на серверах VMware ESX и снижения нагрузки на CPU серверов.

Если посмотреть в документ компании VMware PVSCSI Storage Performance, то там можно увидеть вот такие интересные результаты для производительности дисков виртуальных машин на ESX по сравнению с адаптером LSI:

Однако, когда нужно использовать адаптер PVSCSI для виртуальных машин на ESX? Оказывается, несмотря на его чудесную производительность, не всегда. Согласно вот этой статье Скотта Драммонда, одного из гуру производительности VMware ESX, адаптер PVSCSI нужно использовать только тогда, когда ваше приложение дает значительную нагрузку на дисковую подсистему (high IO workload), а совокупная пропускная способность канала к СХД ее поддерживает (включая то, сколько IOPS может выдавать система хранения).

Вот объяснение данного явления. При росте требований виртуальных машин к дисковой подсистеме возникают interrupt coalescing, то есть объединение прерываний к СХД в пачки для более их быстрой обработки. С помощью этой техники производительность адаптера SCSI увеличивается по сравнению с одиночным выполнением прерываний при большом количестве IO.

На собирание этой пачки требуется какое-то время, поэтому возникает небольшой delay, который потом компенсируется быстрым выполнением команд пачки.

Теперь пара терминов:

• Outstanding IOs (OIOs) - количество запросов на ввод-вывод со стороны виртуальной машины (demand of IO).
• IOs per second (IOPS) - количество запросов на ввод-вывод, которое может обеспечить хранилище (supply of IO).

Так вот LSI адаптер увеличивает этот самый interrupt coalescing на базе как OIOs, так и IOPS по мере роста нагрузки на сторадж. При малом количестве запросов IO, он этот coalescing не использует.

А вот PVSCSI сейчас работает по другому - он использует interrupt coalescing только на базе OIOs. То есть, если растут только требования виртуальных машин к СХД (без роста пропускной способности по IOPS) - начинается interrupt coalescing, соответственно растут задержки.

Для больших же OIOs и IOPS - адаптер PVSCSI дает ощутимый рост производительности и снижает нагрузку на CPU за счет паравиртуализации (на значениях 10-50K IOPS). На нескольких же сотнях IOPS этот эффект практически не ощутим. То есть, если запросы на IO от виртуальных машин больше того, что может выдавать система хранения, то адаптер LSI будет работать эффективнее PVSCSI в силу меньших задержек.

В следующих версиях ESX компания VMware сделает interrupt coalescing на базе как OIOs, так и OIPS, поэтому адаптер PVSCSI будет работать лучше.

Вывод таков - не используйте PVSCSI в окружениях с малой производительностью дисковой подсистемы и низких нагрузках по IO.

А вот, что советует Скотт:

• На данный момент используйте PVSCSI для дисков VMDK, которые находятся на быстром хранилище (более 2,000 IOPS).
• Если у вас есть адаптеры PVSCSI в окружениях с низким IO, не надо их переконфигурировать на LSI, поскольку потери производительности почти незаменты, а приложения все равно не требовательны к ней.
• Для будущих версий VMware ESX / ESXi адаптер PVSCSI будет эффективнее LSI Logic для любых окружений.

Так-то, вот.

Роман Хмелевский, автор известного блога о массивах NetApp, сообщил интересную новость - вышел перевод документа о работе серверов Hyper-V с массивами NetApp:

"Наилучшие методы использования систем хранения NetApp для решений виртуализации Microsoft Hyper-V"

Напомним, что аналогичные документы есть также и для VMware vSphere / ESX.

Документ интересный и полезный, поэтому для пользователей, планирующих внедрение Hyper-V R2 на базе массивов NetApp - просто обязателен к прочтению. Остальные документы по массивам NetApp вы можете найти здесь: http://www.netwell.ru/production/techbiblioteka.php.

Компания NetApp, как вам, наверное, известно, является одним из лидеров в производстве недорогих дисковых массивов NFS и iSCSI, которые работают в качестве хранилищ для серверов VMware vSphere / ESX 4 (а также для инсталляций VMware View 4). Если вы работаете с массивами NetApp, либо просто исследуете возможности подключения СХД к серверам ESX по NFS или iSCSI, вам могут оказаться очень полезными следующие документы:

• Руководство по наилучшим способамиспользования систем NetApp с VMwareVirtual Infrastructure 3 (на русском языке)
• NetApp and VMware vSphere Storage Best Practices (то же самое, только на английском, но для VMware vSphere 4)

В частности, там есть вот такие интересные картинки подключений серверов VMware ESX 4 к дисковым массивам по NFS и iSCSI с разъяснениями:

Благодаря пользователю Romx, мы имеем еще вот эти ссылки:

Пока же хочу обратить внимание, что на вебсайте NetApp есть довольно много подобных документов для разных приложений и задач.
Например:

• NetApp and VMware Virtual Desktop Infrastructure
• Microsoft Exchange 2007 on VMware Infrastructure 3 and NetApp iSCSI Storage
• Oracle VM and NetApp Storage - Best Practices Guide
• NetApp and VMware Building a Virtual Infrastructure from Server to Storage
• NetApp and VMware View Solution Guide: Best Practices for Design, Architecture, Deployment, and Management
• VMware View on NetApp Deployment Guide
• Microsoft Exchange Server, SQL Server, and SharePoint Server Mixed Workload on VMware vSphere 4, NetApp Unified Storage (FC, iSCSI, and NFS), and Cisco Nexus Unified Fabric
• SAP on Windows and Microsoft SQL Server with NetApp Storage and VMware

О компании StarWind мы уже немного рассказывали. Эта компания делает продукт для создания программного iSCSI хранилища для серверов VMware vSphere / ESX, Microsoft Hyper-V и Citrix XenServer под названием StarWind Server.

На данный момент флагманский продукт компании - StarWind Enterprise HA, который позволяет сделать отказоустойчивое хранилище на базе Windows-серверов, например, для VMware ESX, которое в случае отказа одного узла с Datastore виртуальных машин может автоматически переключаться на резервное хранилище, которое синхронизировано с основным.

Но кроме всего прочего, StarWind позволяет сделать RAM Disk и использовать его в качестве виртуального хранилища iSCSI. Совсем недавно компания Intel тестировала свои iSCSI адаптеры для серверов и с помощью ПО StarWind добилась внушительного результата в 1 000 000 IOPS по iSCSI в сети 10 Gbit:

Полностью документ компании Intel можно скачать по этой ссылке.